Security continues to be a concern as people are increasingly conducting personal and/or confidential transactions electronically. In addition, hackers and/or others with malicious intent are becoming increasingly more creative in circumventing existing security measures in devices. To combat new and pervasive incursions by malware and/or viruses, equipment and/or software manufacturers are continuing to make protection measures more intrinsic to the hardware of new devices. For example, large companies including Apple Inc., Microsoft, Inc., etc. are beginning to require that equipment executing their software provide a hardware root of trust. A hardware root of trust may comprise, for example, known valid (e.g., inherently trusted) program files that are used for validating subsequently loaded program files. A hardware root of trust may be, for example, established at device activation based on at least one program file loaded from a read-only memory (ROM) on which platform boot firmware may reside in the device. Any malware, viruses, etc. loaded subsequent to the hardware root of trust may be identified by the hardware root of trust, disabled and/or otherwise prevented from compromising a device.
Existing strategies for establishing a hardware root of trust include loading and executing at least one program file from the ROM in which the platform boot firmware is stored to verify a signature of a subsequently loaded program file. In verifying the file's signature, the previously executed file may authenticate that the subsequently loaded file has been provided from a trusted source based on, for example, a keying algorithm such as RSA, etc. Each program file loaded, verified and executed from the platform boot firmware ROM may then verify the signature of the subsequently loaded program file, and so on until all program files are loaded from the platform boot firmware. While implementing this signing-based chain methodology may ensure that all of the files loaded during device activation are signed, and thus valid, there are some drawbacks. Signing increases file size, and likewise, the amount of memory resources used when each file is loaded. Signature verification requires a substantial amount of time for each file that is verified. Both of these requirements increase substantially when signing is conducted serially for all files to be loaded from the platform boot firmware. These memory and time requirements can delay device startup, negatively impact user experience, add to the cost of the device, etc.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications and variations thereof will be apparent to those skilled in the art.